昨天講到五位隊友的判斷力已經趨同，開放型任務可以全員並進。今天講那句話不成立的地方。

有一類限制，不管模型多聰明都不會消失：它跑在什麼樣的沙箱裡。

第一次撞牆：發布

2026 年 7 月 3 日，課程網站要發布上線。這活很單純：建 repo、推上去、開 GitHub Pages。

我派給立霧，因為這是典型的「執行風險」——要動工具、要落地、要快。

他接了活，做了發布前的準備。然後回報：推不上去。

我不信，叫他加上放寬權限的參數再試一次，連網路存取都開了。他再試，回報：連 gh auth status（查「我現在登入了沒」的唯讀指令）都被政策擋掉。

不是憑證過期，不是網路不通，是那個沙箱從設計上就不讓他碰。

後來連改檔也一樣。兩種放行旗標都給了，錯誤訊息永遠是同一句：

patch rejected: writing is blocked by read-only sandbox

-s workspace-write 給了、--full-auto 也給了，照擋。這不是旗標語法問題，是這台機器上的沙箱硬牆。最後的分工變成：立霧出碼、把整份檔案內容印到終端輸出（stdout），我讀完落檔、build、驗證。他負責想，我負責碰檔案系統。

從那次之後，能力表上多了一條：發布、推 repo、開 Pages 這類活由我來做，立霧負責蓋、不負責推。

第二次撞牆：改檔

7 月 12 日，另一件要改檔的活，明確加了可寫入的參數。

他跑完了。我去看檔案，沒有變——要寫進檔案的內容，只出現在他的輸出裡，檔案本身動都沒動。

這種失敗最難查，因為表面上的訊號看起來都像做完了。

現在那台機器的規矩是：改檔的活別派他，我自己動手，他負責唯讀複驗。

第三次撞牆：出圖存檔

出圖這件事更有意思。時間上它其實發生得最早（7 月 2 日，比第一次撞牆還早一天），放到最後講，是因為它把分工這件事講得最清楚。

立霧畫得出來，畫得還很好。但他把圖存到我指定的路徑時會被擋，即使給了寫入權限。圖不是沒生成，是生成完落在他沙箱裡自己的產物目錄。

解法很土：叫他回報產物路徑，我自己去搬。

所以我們多了一張表

這三次之後，主指令旁邊多了一張能力實測表。今天這三次撞牆，正好就是表上的其中三列（節錄自真表，欄位照搬）：

規矩是：只寫已經驗證過的，沒驗證的標「待確認」；換機器時，綁沙箱的能力一律重驗。

這張表跟昨天講的派工合約是兩回事，不能混：

派工合約回答「這件事該找誰」，講的是任務的性質。能力實測表回答「他到底做不做得到」，講的是沙箱的物理限制。前者可以靠想的，後者只能靠測的。

判斷力趨同這件事的正確講法

我後來在主指令裡把話補完整了，大意是：

判斷力拉平了，但綁在載體上的物理硬條件沒有。推 git、碰個資、讀得到自己的輸出、開得了瀏覽器——這些是沙箱的物理牆，派動作之前要查實測表。

說到底，你派出去的永遠是「模型＋它所在的沙箱」這個組合。前者會進步，後者由別人決定。

明天講這張表本身怎麼設計，以及為什麼它上面每一列都要押日期。